[main] Update dependencies from microsoft/LiftedIXP/DCPP - #6636

* Remove github-artifacts mcp server (#6684)

* Remove github-artifacts mcp server

* Update review prompts for GitHub MCP migration (#6686)

Remove references to the retired github-artifacts helper and direct issue and PR review workflows to Copilot's standard web, file, and execution tools.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 2b34993b-0dcf-4789-94c5-97fd92cce84d

---------

Co-authored-by: Gordon Lam <73506701+yeelam-gordon@users.noreply.github.com>
Copilot-Session: 2b34993b-0dcf-4789-94c5-97fd92cce84d

* MSIX: Always include PackageIntegrity/Content[Enforcement=on] in VS project templates (#6613)

* Bump VSIX build .NET SDK to 10.0.111 (security release) (#6699)

* Pin .NET SDK to patched 10.0.111 (CG DOTNET-Security-10.0)

Component Governance flags a vulnerable .NET SDK (10.0.101) against
/global.json. That version string is not in the repo -- global.json has
no "sdk" block at all, so builds resolve whatever SDK the agent image
happens to carry, and CG attributes what it detects to the nearest
manifest. Note "tools.dotnet" is a non-standard bootstrap field and does
not govern SDK resolution; only an "sdk" block does.

Pins sdk.version to 10.0.111 (runtime 10.0.11, 2026-08-11 security
release). Staying in the 1xx feature band already used here avoids
unrelated MSBuild/SDK/analyzer behavior changes.

Also bumps BuildVSIX 10.0.110 -> 10.0.111 so an SDK satisfying the pin is
actually installed -- rollForward only rolls forward, never backward.
That is independently a security improvement: 10.0.110 carries runtime
10.0.10 and is one security release behind. Follows up #6624.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 5474160f-e555-4254-899b-783ad9211b71

* Remove root global.json SDK pin; scope PR to VSIX only

The root global.json `sdk` block is a repo-wide floor for every dotnet/MSBuild
invocation beneath it. Foundation/MRT/PREfast jobs install only .NET SDK 6.0.414
(matched to the shipping net6.0 / net6.0-windows10.0.19041.0 TFMs), and
rollForward never rolls backward across majors -- so Microsoft.NET.Sdk became
unresolvable and 10 CI jobs failed with MSB4236.

Scoping this PR to the BuildVSIX 10.0.110 -> 10.0.111 bump only. The CG
global.json remediation requires installing the pinned SDK in every job that
restores under the root global.json, and will be handled separately.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 484c9277-ea15-4f85-a4a0-0429347ade48

---------

Co-authored-by: Vineeth Thomas Alex <vithoma@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 5474160f-e555-4254-899b-783ad9211b71
Copilot-Session: 484c9277-ea15-4f85-a4a0-0429347ade48

* [main] Update dependencies from microsoft/LiftedIXP/DCPP (#6636)

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260717.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1897.260717-1605.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260717.1

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260719.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1898.260719-1733.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260719.1

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260723.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1899.260723-1213.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260723.1

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260727.2
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1900.260726-2015.1
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260727.2

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260729.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1901.260728-1900.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260729.1

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260806.3
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1902.260806-0506.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260806.3

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260814.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1903.260814-0918.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260814.1

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260818.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1904.260818-1237.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260818.1

* Update dependencies from https://dev.azure.com/microsoft/LiftedIXP/_git/DCPP build 20260823.1
On relative base path root
Microsoft.FrameworkUdk , Microsoft.ProjectReunion.InteractiveExperiences.TransportPackage From Version 3.0.0-experimental-27300.1896.260713-1015.0 -> To Version 3.0.0-experimental-27300.1905.260822-1925.0
Microsoft.WindowsAppSDK.InteractiveExperiences From Version 3.0.0-experimental-Rolling.20260713.2 -> To Version 3.0.0-experimental-Rolling.20260823.1

---------

Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>

* [57514396] Use the central TSA area path in Foundation native builds

* Fix "Cancel" button in the C# and C++ wapproj templates so that it returns to the "Configure your new project" menu instead of creating a broken project (#6708)

* Add nuget cli alternative to Test-DotnetnNewTemplates for local execution

* Add check in Build-VSIX-Local to verify that the templates are included in the VSIX

* Add MsBuild parameter to build and install VSIX scripts

* Set WindowsAppSDkVersion, WindowsSdkBuildToolsVersion,and WindowsSdkBuildToolsWinAppVersion to {name}$ (parent template parameter) instead of project template parameter

* Move the Windows platform selection wizard from the Wapproj.vstemplate to the PackagedApp.vstemplate

* Move the Windows platform selection wizard from the C++ Wapproj.vstemplate to the PackagedApp.vstemplate

* Substitute publisher name from parent project in C++ wapproj Package.appxmanifest

* Rename VsVersion in help guide to MsBuildVersion

* Update missing MSBuild error message to include the MsBuildVersion selected in the script

* Remove duplicate problems.Count newline

* Remove extra excludedVersionPrefixes in Test-DotnetNewTemplates.ps1

* Add Reactor (Microsoft.UI.Reactor) dotnet new templates (#6620)

* Add Reactor (Microsoft.UI.Reactor) dotnet new templates

Adds four Reactor project templates to the Microsoft.WindowsAppSDK.WinUI.CSharp.Templates dotnet-new pack, mirroring the WinUI templates but for Microsoft.UI.Reactor (pure C#, no XAML):

- Reactor Blank App        (reactor, reactor-blank)
- Reactor MVU App          (reactor-mvu)
- Reactor NavigationView   (reactor-navview)
- Reactor TabView App      (reactor-tabview)

Wired into dev/Templates/templates.props via the DotnetNewOnlyProjectTemplate
slot (dotnet-new only, no VSIX, no manifest; Reactor apps run unpackaged).
Each shares a common csproj referencing Microsoft.UI.Reactor +
Microsoft.WindowsAppSDK, bundles the WinAppSDK runtime self-contained, and
enables the Debug-only Reactor devtools surface. README and
Test-DotnetNewTemplates.ps1 updated to document and validate the new templates.

Validated end-to-end: pack -> install -> dotnet new -> build (Debug + Release)
for all four templates.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Fix Reactor template runtime crash: remove TitleBar icon

TitleBar(...).Icon(FontIcon(...)) threw System.ArgumentException (E_INVALIDARG)
at runtime when Reactor set TitleBar.IconSource on Windows App SDK 2.1.3, so
the scaffolded Blank, MVU, and TabView apps crashed on launch. The glyph was
only a placeholder, so drop the icon; the title bar still shows the title text
and all four templates now launch cleanly (validated with dotnet run).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Bump Reactor templates to preview.12 and restore title-bar icon

microsoft/microsoft-ui-reactor#855 fixes the IconResolver FontSize=NaN crash
(FontIcon in an IconSource slot without an explicit size threw
ArgumentException from TitleBar.set_IconSource). That fix ships in
Microsoft.UI.Reactor 0.1.0-preview.12, so restore the placeholder title-bar
app-mark icon in the Blank, MVU, and TabView templates and bump the default
reactorVersion 0.1.0-preview.11 -> 0.1.0-preview.12 across all four templates.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Provision .NET 10 SDK in dotnet-new templates test stage

The template smoke-test stage installed only .NET SDK 8.0.x, so scaffolding
and building the Reactor templates failed with NETSDK1045 (Reactor targets
net10.0 and declares a [10.0,) sdk-version constraint). The WinUI templates
auto-detect their TFM from the active SDK, so they built net8.0 and passed,
masking the gap.

Add a second UseDotNet@2 step (param reactorDotnetSdkVersion, default 10.0.x)
to the shared Test-Stage template so the agent has the .NET 10 SDK. Verified
locally that the WinUI templates still build cleanly on the .NET 10 SDK, so
existing coverage is unaffected. Both the official and PR pipelines consume
this shared stage.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Address PR review: trim launchSettings comments, use per-template icons

Review feedback from @DinahK-2SO on #6620:
- Remove the explanatory comment block from the Reactor launchSettings.json
  files (the content overlapped the package README).
- Give the MVU, NavigationView, and TabView templates their own icon.png
  (reusing the existing WinUI mvvm/navigation/tabview template icons) instead
  of all reusing the blank-app icon.

The packaging/taskbar-icon, tabs-in-title-bar, and winui-* short-name comments
are still open pending a check with the Reactor team.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Add winui-reactor* short-name aliases to Reactor templates

Review feedback from @DinahK-2SO on #6620: give each Reactor template a
winui-reactor* alias (winui-reactor, winui-reactor-mvu, winui-reactor-navview,
winui-reactor-tabview) so they also surface under 'dotnet new list winui'
alongside the other WinUI templates. README updated to note the aliases.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* reactor-tabview: integrate tabs into the title bar

Review feedback from @DinahK-2SO on #6620: instead of stacking a separate
TitleBar row above the TabView, put the tabs up in the title bar (Edge/Terminal
style) to look cleaner and save vertical space.

Uses supported Reactor APIs: UseWindow().NativeWindow with
ExtendsContentIntoTitleBar + SetTitleBar, the TabView TabStripHeader (app name
at the leading edge) and TabStripFooter (draggable region), and UseDpi +
UseWindowSize to reserve the caption-button inset (RightInset) across DPI and
resize. Verified by scaffolding the template, building, running, and
screenshotting the window: the tabs render inline in the title bar with the
caption buttons clear.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Make Reactor templates packaged (MSIX) and match the WinUI templates

Per review direction, the four Reactor templates now:

1. Are single-project MSIX packaged (like the WinUI templates) instead of
   unpackaged. Each gains app.manifest, Package.appxmanifest (EntryPoint
   Windows.FullTrustApplication since Reactor has no XAML App class), the shared
   Assets, and PublishProfiles. The csproj switches to EnableMsixTooling +
   Microsoft.Windows.SDK.BuildTools + Microsoft.Windows.SDK.BuildTools.WinApp so
   'dotnet run' registers a loose package and launches with MSIX identity.
   templates.props sets RenameManifestFrom and the template.json files gain the
   publisher / guid / build-tools-version symbols and the \\$
   modifier.

2. Visually match their WinUI counterparts:
   - reactor      -> title bar (app icon) + empty content (blank canvas).
   - reactor-mvu  -> centered 'Hello, WinUI!' + [+]/[-] icon counter (keeps the
     UseReducer MVU pattern under the same UI).
   - reactor-navview -> title bar + NavigationView Home/About + built-in Settings;
     pages render 'Title' + 'This is the X page'.
   - reactor-tabview -> MicaAlt, app-icon TabStripHeader, closable Home/About tabs
     with a '+' add button, tabs in the title bar.

Validated end-to-end for all four: pack -> install -> scaffold -> build ->
dotnet run (launches packaged with identity) -> screenshot matches the WinUI
counterpart. README updated (templates are now packaged).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* reactor-mvu: greet 'Hello, Reactor!'; use WinUI type-ramp styles for font parity

- MVU greeting is now 'Hello, Reactor!' (was 'Hello, WinUI!').
- Switch the Reactor text from Heading()/.SemiBold() (raw 28px Bold-700) to the
  type-ramp factories Title()/BodyStrong()/Body(), which apply the actual WinUI
  styles (TitleTextBlockStyle 28px Semibold-600, BodyStrongTextBlockStyle,
  BodyTextBlockStyle). This makes the Reactor headings/body render with the same
  weight and Segoe UI Variable optical size as the WinUI templates instead of a
  heavier bold. Applied to the mvu, navview, and tabview page text.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* reactor-tabview: give tab pages a solid background to match WinUI

The WinUI TabView template's pages set Background=SolidBackgroundFillColorTertiaryBrush,
which covers the window's Mica in the tab content area. The Reactor version left
the pages transparent, so MicaAlt showed through the content. Wrap the tab page
content in a Border painted with that same tertiary brush so the content is a
solid surface and only the tab strip / title bar show Mica, matching X_Tab.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* reactor-tabview: stretch the tab page surface to fill the content area

The solid tertiary page background only covered the text at the top because
Reactor sizes the tab content to the element's desired size. Force the page
Border to HorizontalAlignment/VerticalAlignment Stretch so the solid surface
fills the whole tab content region, matching the WinUI TabView template
(verified: the content is a uniform solid fill down to the window bottom).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Fill reactor-tabview page surface to window height

Match the WinUI TabView template's uniform tertiary content background by
sizing the shared page surface to the window height, so it fills the whole
tab content area instead of shrinking to its text (two-tone with Mica below).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Use Reactor's navigation system in reactor-navview

Match the WinUI NavigationView template's shell: the title bar owns the back
and pane toggle buttons, and NavigationView's own copies are hidden.

Switch from hand-rolled tag state to Reactor's navigation handle
(UseNavigation + NavigationHost), so the title bar back button is wired by
.WithNavigation(nav) and tracks the back stack instead of never appearing.
Also request the tall title bar layout the WinUI template uses.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Toggle the nav pane on the control instead of mirrored state

NavigationView opens and closes its pane on its own (light dismiss, display
mode changes), so a separate IsPaneOpen state copy drifted out of sync and
the title bar toggle needed two clicks to take effect.

Flip IsPaneOpen on the control directly, the same way the WinUI template's
code-behind does.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Match the WinUI page transition in reactor-navview

Reactor's NavigationHost slides pages in from the side, while WinUI's Frame
defaults to an entrance transition that rises the new page up into place.
Slide from the bottom so switching pages animates the same way.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Trim the Reactor templates to match the XAML templates' style

The Reactor templates carried long comments explaining Reactor concepts and
how they differ from XAML, which made them read like documentation rather
than a starting point. Keep only the brief, functional comments the XAML
templates use, and a single pointer to the Reactor project info.

Also drop the explicit navigation transition from reactor-navview: matching
the XAML Frame's entrance animation added verbosity and called out a
difference between the two, so use Reactor's default instead.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Mark the Reactor templates as experimental

Microsoft.UI.Reactor is prerelease and its API may still change, so label the
templates accordingly: add `(Experimental)` to each template name, an
`Experimental` classification so it shows in the dotnet new tags column, and
a note in each description and in the README.

Also correct the templates.props comment, which still described the Reactor
apps as unpackaged with RenameManifestFrom unset; they are packaged
(single-project MSIX) and do set it.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Fix Reactor analyzer warnings in the MVU and TabView templates

The templates tripped four of Reactor's analyzers, so a freshly scaffolded
project did not build clean:

- REACTOR_A11Y_001 (x2): the MVU counter's icon-only buttons had no
  accessible name. Add .AutomationName().
- REACTOR_A11Y_002: the TabView tab strip icon is decorative. Mark it
  .AccessibilityHidden().
- REACTOR_HOOKS_013: the initial tab array was reallocated on every render
  though only read on the first. Wrap it in UseMemo.
- REACTOR_POOL_001: the page surface set MinHeight via .Set(...), which is
  reset when the element returns to the pool, so the tab content fill could
  be lost on re-render. Use the .MinHeight() modifier instead.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Use $targetentrypoint$ in the Reactor manifests, like the XAML templates

The Reactor manifests hardcoded EntryPoint=Windows.FullTrustApplication while
every XAML template uses the $targetentrypoint$ token. The token already
resolves to Windows.FullTrustApplication for these projects, so the generated
AppxManifest.xml is unchanged - this just removes an unexplained difference
between the two sets of templates.

The four Reactor manifests are now byte-identical to their XAML counterparts.

Verified: all four scaffold, build warning-free, generate the same
EntryPoint=Windows.FullTrustApplication, and launch with package identity.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Commit the Reactor templates' publish profiles

The root .gitignore has a blanket `*.pubxml` rule, so the three publish
profiles in each Reactor template were silently never added. They existed
only on the authoring machine; a clean clone got none of them. The WinUI
templates force-added theirs in #6407 for the same reason.

Without the profiles the csproj's
`<PublishProfile Condition="Exists(...)">` never resolves, so SelfContained
is never set to true. Combined with PublishTrimmed=true for non-Debug
configurations that fails a Release build outright:

  error NETSDK1102: Optimizing assemblies for size is not supported for the
  selected publish configuration. Please ensure that you are publishing a
  self-contained app.

Force-add all 12 files so Release builds and publish work from a fresh
clone, matching the WinUI templates.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Stop .gitignore from swallowing template publish profiles

The blanket `*.pubxml` rule silently ignored the Reactor templates' publish
profiles, so they were never committed and Release builds failed from a
clean clone (fixed in 8ea4586 by force-adding them).

`git add -f` fixed those 12 files but not the mechanism: the next template
added, or a new RID added to an existing one, hits the same trap and it is
again invisible to anyone whose working tree still has the files on disk.

Add a `!dev/Templates/**/*.pubxml` negation alongside the existing one for
dev/vsix, so template publish profiles are committable by default. Publish
profiles elsewhere in the repo stay ignored.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Match the XAML templates' icon font and size

The Reactor templates hardcoded `Segoe Fluent Icons` on their FontIcons and
left the size at WinUI's default. The XAML templates do neither: they use
`<FontIcon Glyph="..." />` with no FontFamily, inheriting SymbolThemeFontFamily,
which resolves the right icon font for the OS — worth keeping given the
templates support Windows 10 1809 and Segoe Fluent Icons is Windows 11 era.

The MVVM template also sets FontSize="14" on its counter icons, which ours
missed, so the buttons rendered larger than their XAML counterpart:

  XAML MVVM      58x41
  Reactor MVU    67x51  ->  58x42

Verified against Microsoft.UI.Reactor 0.1.0-preview.12: both templates build
warning-free and the glyphs render correctly (Icon(FontIcon(...)) resolves
through IconResolver, not the Button(string) content path).

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Update Reactor dotnet new templates for 0.1.0-preview.13

Reactor preview.13 adds declarative APIs that let the Navigation and
TabView templates drop their imperative escape hatches:

- NavigationView: use IsBackButtonVisible / IsPaneToggleButtonVisible and
  .IsPaneOpen(value, handler) instead of UseRef + OnMount downcast, and
  select the built-in Settings item via NavigationViewElement.SettingsTag.
  OnSelectedTagChanged still reports null for Settings by design, so
  TagToRoute keeps handling both SettingsTag and null.
- TitleBar: use .Tall() instead of the UseEffect + DispatcherQueue hop and
  the redundant .Height(48).
- TabView: set FillContentArea, removing the MinHeight workaround.

Also bump the reactorVersion default to 0.1.0-preview.13 in all four
Reactor template.json files.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509

* Let the OS size the window, like the XAML templates

Drop the hardcoded 1000x700 from all four Reactor templates. Reactor
PR #924 makes ReactorApp.Run's width/height optional, so omitting them
lets the OS pick the size, matching the XAML templates which set no
size at all. Verified identical to a freshly scaffolded XAML app.

This requires 0.1.0-preview.13; before #924, omitting width/height
meant a hardcoded 1024x768 rather than an OS-chosen size.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509

* Add the MsixPackage launch profile to the Reactor templates

The Reactor templates were originally unpackaged and their launchSettings.json
only declared `commandName: Project` profiles. Making them single-project MSIX
updated the csproj and added Package.appxmanifest but left launchSettings
behind, so F5 from Visual Studio failed:

  ...launchSettings.json does not contain a profile with commandName
  'MsixPackage'. To debug a packaged single-project MSIX solution, a profile
  with command name MsixPackage in launchSettings.json is required.

`dotnet run` goes through Microsoft.Windows.SDK.BuildTools.WinApp instead, so
it worked throughout and the gap went unnoticed.

Declare the same Package / Unpackaged pair the WinUI XAML templates ship, with
Package first so it is the F5 default, and keep the Reactor devtools profile
alongside them.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Float the Windows App SDK version in the Reactor templates

The Reactor templates pinned Microsoft.WindowsAppSDK to 2.1.3 while the WinUI
XAML templates default to `*`. That pinned new projects to an older SDK than
the one Visual Studio offers everywhere else — 2.3.1 is current, so scaffolded
Reactor apps were two releases behind for no reason.

2.1.3 was the version Reactor happened to be built against, not a hard floor:
Microsoft.UI.Reactor 0.1.0-preview.13 depends on Microsoft.WindowsAppSDK.WinUI
>= 2.1.0. Keep the requirement in the parameter description rather than
encoding it as the pin, matching the WinUI templates.

Verified with the floated default: all four templates resolve
Microsoft.WindowsAppSDK 2.3.1, build warning-free, and launch with package
identity.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Accept MSB4181 for the invalid-version restore test on .NET SDK 10

The dotnet-new template test stage previously installed only the .NET 8 SDK.
Adding the .NET 10 SDK (needed because the Reactor templates target net10.0)
means the muxer now selects 10.0.400 for the pre-existing winui negative
tests as well, which changes the diagnostic NuGet emits for an unparseable
package version:

  SDK 8.0.424 / 9.0.317 : no error code; "'not-a-version' is not a valid
                          version string."
  SDK 10.0.400          : MSB4181 - RestoreTask returns false without
                          logging the descriptive error, so no NU code
                          surfaces at all.

The old assertion short-circuited on any error code being present and
demanded NU1105, so MSB4181 failed the run. (NU1105 never actually
surfaced on any tested SDK; the test passed via the descriptive-message
fallback.) Accept NU1105/MSB4181 or the descriptive message, and stop a
code's presence from bypassing the fallback.

Verified on 8.0.424 / 9.0.317 / 10.0.400. Unrelated failures (NU1101,
NU1301) still fail the assertion, so it is not weakened to "any failure".
Scenario 5's build check (NETSDK1004), scenario 6 (NU1102) and scenario 7
(NU1301) were confirmed unchanged on SDK 10.

Also corrects an adjacent comment that said NETSDK1005 where the check and
the observed behaviour are both NETSDK1004.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Pin the Reactor test-stage .NET SDK instead of floating 10.0.x

Every other UseDotNet@2 task in this repo pins an exact SDK (6.0.414,
6.0.427, 8.0.100, 9.0.200, 10.0.111); #6624 added the BuildVSIX pin so
Component Governance scans a patched toolchain, and #6699 bumped it
deliberately for a security release. reactorDotnetSdkVersion was the only
new floating pin.

Floating is what broke CI: '10.0.x' resolved to 10.0.302 when the task was
added on 2026-07-23, then silently jumped a whole feature band when 10.0.400
shipped on 2026-08-11. 10.0.400 changed the NuGet diagnostic for an
unparseable package version, so the pre-existing winui invalid-version smoke
test started failing with no corresponding source change.

Pinned to 10.0.400 rather than the 10.0.111 used by BuildVSIX. The Reactor
templates cannot use the 1xx servicing band: Microsoft.UI.Reactor's analyzers
and source generators (Reactor.Analyzers, Reactor.Wrappers.Generator,
Reactor.Localization.Generator) reference Roslyn 5.6.0.0, and 10.0.111 ships
Roslyn 5.0.0.0, so all three are silently disabled with CS9057 while the
build still reports success. Verified by building the same scaffolded project
on both SDKs: 10.0.111 -> 3x CS9057, 10.0.400 (Roslyn 5.9.0.0) -> 0 warnings.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Accept NETSDK1005 for the invalid-version build test on .NET SDK 10

Follow-up to 5ff625e, which fixed the restore assertion in the same
scenario. The build assertion immediately after it failed for the same
underlying reason.

On .NET SDK 10 NuGet's RestoreTask fails (MSB4181) but still writes a
partial obj/project.assets.json. The subsequent --no-restore build therefore
reports NETSDK1005 (assets file has no target for the project's TFM) rather
than NETSDK1004 (assets file missing). Accept either, since both mean restore
did not produce usable assets. Scenario 7's list gains NETSDK1005 for the
same reason; it currently resolves to NU1301, but NETSDK1004 is in that list
for the 'restore never succeeded' case whose SDK 10 equivalent is 1005.

This also reverts the NETSDK1005 -> NETSDK1004 comment change from 5ff625e.
That comment was correct as written; I changed it based on a repro that used
a bare net8.0 project with no obj directory, which produces NETSDK1004 and
does not reproduce the real template's behaviour. Re-verified with a faithful
repro (net10.0-windows10.0.26100.0, WinUI props, same build flags), which
reproduces CI exactly: assets file present after the failed restore, build
fails with NETSDK1005.

All four error-code assertions in this script are now backed by faithful
repros on the pinned SDK 10.0.400: restore MSB4181, build NETSDK1005,
scenario 6 NU1102, scenario 7 NU1301. Unrelated failures still throw.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1
Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509

* dotnet new WinUI3 templates 0.0.7-alpha (#6729)

* Propagate the PackageReference version into the C# wapproj template's BlankApp project file (#6705)

* Fix AppInstance process handle validation (#6733)

* Fix AppInstance process handle validation

Open non-current processes with SYNCHRONIZE once and transfer the
validated handle into AppInstance before registering the termination wait.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Potential fix for pull request finding

Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>

* Set ApplicationIcon in the C# app templates (#6728)

* Set ApplicationIcon in the C# app templates

The eight C# app templates ship Assets\AppIcon.ico and reference it from the
window (AppWindow.SetIcon in the XAML templates, TitleBar.Icon in the Reactor
ones), but none of them set <ApplicationIcon>, so the icon was never embedded
into the built executable as a Win32 icon resource. Explorer, shortcuts, and
the taskbar for an unpackaged build therefore showed the default .NET icon.

Guarded with Condition=Exists so the property is simply skipped if a project
does not have the asset, matching the existing PublishProfile pattern in these
same templates.

Applied to all eight app templates that ship the asset -- the four WinUI XAML
ones and the four Reactor ones -- rather than only the Reactor set, so the
templates stay consistent with each other. ClassLibrary, PackagedApp, and
UnitTestApp do not ship an AppIcon.ico and are untouched.

Only ProjectTemplate.csproj is modified: that is the file scaffolded for the
user by both dotnet new and the VSIX. The WinUI.Desktop.Cs.*.csproj files are
VSSDK packaging projects for the VSIX itself, not scaffolded output.

Validated by scaffolding and building all eight templates (Debug, x64): all
build clean and the icon is embedded in the produced exe, confirmed by
ExtractAssociatedIcon returning a 32x32 icon for each. The two warnings from
winui-mvvm are pre-existing MVVMTK0045 diagnostics from the MVVM Toolkit and
are unrelated.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Bump Reactor to 0.1.0-preview.14 and drop the explicit title bar icon

Reactor 0.1.0-preview.14 makes TitleBar(...) inherit the window's icon
(microsoft/microsoft-ui-reactor#1153), so the explicit
.Icon("ms-appx:///Assets/AppIcon.ico") in the templates is now redundant.
Removing it keeps the scaffolded App.cs to the shape a starter template
should have, and the title bar still renders the app mark.

Applies to the three templates that use a TitleBar element: ReactorBlankApp,
ReactorMvuApp and ReactorNavigationApp. ReactorTabViewApp has no TitleBar --
it extends content into the title bar with a custom drag region and renders
its icon through TabStripHeader = Image(...), which is a different surface
that the inherit behaviour does not cover -- so it keeps its explicit
reference and is intentionally untouched.

Validated against the real 0.1.0-preview.14 package, four scaffolded apps,
with the icon line present and absent:

  control, .Icon present, preview.14    title bar mark shown
  line removed, preview.14              title bar mark shown  <- the change
  line removed + icon: arg, preview.14  title bar mark shown
  line removed, preview.13              NO mark

The last row is the negative control: identical source and capture method,
only the package version differs, so the mark on preview.14 is caused by the
inherit behaviour rather than by something incidental.

All four templates were then scaffolded from the built pack and built clean
on x64: Debug 0 warnings, Release 2 warnings. The Release warnings are
pre-existing IL2104 trim warnings from Microsoft.Windows.SDK.NET and
WinRT.Runtime, unrelated to this change and present without it.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

---------

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1

* Fix errors from missing resource dll with version info (#6725)

* [57514396] Use central TSA config for Foundation source analysis (#6738)

* Normalize line endings in AppInstance.cpp (#6752)

* AppNotificationManager::Show and AppInstance::GetInstances: refactor to noexcept workers (Bug 61688595) (#6714)

Refactor two hot-path WinRT projection entry points so a failed HRESULT does not trigger the deep C++/WinRT projection rethrow path that exhausted the stack via WIL's FormatMessage-based exception logging chain inside ResultFromCaughtException_CppWinRt::catch$8 (the Watson failure signature for this crash bucket).

AppNotificationManager::Show: move the throwing body into a private noexcept HRESULT worker (ShowImpl) using RETURN_HR_IF / RETURN_IF_FAILED / CATCH_RETURN. The public Show keeps the IsSupported() early-return and rethrows any failure HRESULT via THROW_IF_FAILED(ShowImpl(...)).

AppLifecycle::AppInstance::GetInstances: same pattern. The body becomes GetInstancesImpl(IVector<AppInstance>& out) noexcept; the public GetInstances() is a thin THROW_IF_FAILED(GetInstancesImpl(...)) wrapper. Internal callers (RedirectActivationToAsync at line 636) are unaffected because the public signature is unchanged.

These are the two entry points observed in the Watson cabs attached to this bucket: WinUI3 Controls Gallery cabs originate in Show, and the auto-filer cab originates in Photos -> AppInstance::GetInstances (frames 16-22 in the cab call stack). The catch handler one frame deeper is mis-attributed by Watson's PDB walker to SecurityDescriptorHelpers::NonDelegatingGetTrustLevel::catch$0 (lexically-nearest catch symbol).

AB#61688595

Co-authored-by: James Pike <jamespik@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Retire the standalone StoragePickersTestApp (#6779)

Remove the specialized UI harness, its assets, and solution mappings to simplify ongoing build maintenance. Keep the Storage Pickers implementation and automated tests unchanged.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Change WindowsAppSDK-DotnetNewTemplates template from Microsoft.NonOfficial to Microsoft.Official template (#6783)

* Add OneBranch.Official.CrossPlat.yml template to WindowsAppSDK-DotnetNewTemplates.yml

* Use Microsoft Official template for dotnet templates

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 30bef3b6-3b91-4f20-96cd-7c242a8a370f

---------

Copilot-Session: 30bef3b6-3b91-4f20-96cd-7c242a8a370f

* Add network isolation to WindowsAppSDK-DotnetNewTemplates.yml (#6787)

* Use path filter for template PR validation (#6782)

* Skip OneBranch tool download when running template change validation on PRs from forks

* Use ADO path filter for template PR validation

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: 6baeec26-f59b-466a-8eab-cd3b09b19380

---------

Copilot-Session: 6baeec26-f59b-466a-8eab-cd3b09b19380

* Reactor templates: bump to 0.1.0-preview.16 and raise WindowsAppSDK floor to 2.2.0 (#6786)

Updates the four Reactor dotnet-new templates for the 0.1.0-preview.16 release:

  reactorVersion       0.1.0-preview.14 -> 0.1.0-preview.16
  windowsAppSdkVersion documented floor 2.1.3 -> 2.2.0

microsoft/microsoft-ui-reactor#1259 adopts ApplicationData.GetForUnpackaged(),
a Windows App SDK 2.2.0 API, and raises Microsoft.UI.Reactor's dependency on
Microsoft.WindowsAppSDK.WinUI to 2.2.1. Verified that commit is contained in
the v0.1.0-preview.16 tag, and that Directory.Build.props at that tag declares
WindowsAppSDKVersion 2.2.0 / WindowsAppSDKWinUIVersion 2.2.1.

These templates reference the full Microsoft.WindowsAppSDK metapackage (not the
lean WinUI sub-package) and scaffold packaged single-project MSIX apps, so the
correct consumer floor is metapackage 2.2.0 - the first version whose WinUI
dependency is 2.2.1 (2.1.3 -> WinUI 2.1.0; 2.2.0 -> WinUI 2.2.1).

Both edits ship together because the mismatch they prevent is silent, not a
restore error. Measured with a stub package carrying the post-#1259 dependency
shape: pinning --wasdk-version 2.1.3 restores with exit code 0 and zero
warnings, resolving Microsoft.WindowsAppSDK.WinUI 2.2.1 while the metapackage
holds Microsoft.WindowsAppSDK.Runtime at exactly [2.1.3]. WinUI is only ever a
transitive reference, so NuGet takes the highest floor and never reports
NU1605; the result is 2.2.1 reference assemblies over a 2.1.3 runtime, which
builds clean and fails at runtime. The same probe at 2.2.0 resolves Runtime
2.2.0. Since the toolchain raises no error, the description text is the only
guardrail a user pinning explicitly will ever see.

Validated by scaffolding all four templates from a locally packed template
pack: each emits Microsoft.UI.Reactor and Microsoft.UI.Reactor.Devtools at
0.1.0-preview.16, Microsoft.WindowsAppSDK at the default '*', and a
Package.appxmanifest. Also verified the explicit pin path
(--wasdk-version 2.2.0 --reactor-version 0.1.0-preview.16).

Restore/build validation is deferred to CI: 0.1.0-preview.16 is on nuget.org
but has not yet mirrored to the internal package proxy reachable from this
machine.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>

* Pin GitHub Actions to full-length commit SHAs (#6791)

Co-authored-by: Dan Fiedler <danfiedler@microsoft.com>

* Retry transient bootstrap initialization registration failures in tests (#6816)

* Retry transient bootstrap initialization failure

Retry MddBootstrapInitialize only when DDLM registration is temporarily unavailable, using a bounded exponential backoff.

AB#62489699

* Migrate TouchDownBuild-WinAppSDK  (#6814)

* Fix TouchDown variable group

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837

* Fix TouchDown service connection

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837

* Use TouchDown Azure resource connection

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837

---------

Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837

---------

Co-authored-by: Roman Sivak (AKVELON INC) <v-romansivak@microsoft.com>
Co-authored-by: ssparach <128866445+ssparach@users.noreply.github.com>
Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837

---------

Co-authored-by: Lauren Ciha <laurenciha@microsoft.com>
Co-authored-by: Gordon Lam <73506701+yeelam-gordon@users.noreply.github.com>
Co-authored-by: Howard Kapustein <howardk@microsoft.com>
Co-authored-by: Vineeth Thomas Alex <vineeththomasalex@gmail.com>
Co-authored-by: Vineeth Thomas Alex <vithoma@microsoft.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
Co-authored-by: v-goradojcic <v-goradojcic@microsoft.com>
Co-authored-by: Alexandre Zollinger Chohfi <alzollin@microsoft.com>
Co-authored-by: Dinah Xiaoman G <116714259+DinahK-2SO@users.noreply.github.com>
Co-authored-by: Scott Jones <sjones@microsoft.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Manodasan Wignarajah <mawign@microsoft.com>
Co-authored-by: Dreynor87 <wall_c.s@outlook.com>
Co-authored-by: James Pike <jamespik@microsoft.com>
Co-authored-by: Dan Fiedler <danfiedler@microsoft.com>
Co-authored-by: romsi1983 <41230962+romsi1983@users.noreply.github.com>
Co-authored-by: Roman Sivak (AKVELON INC) <v-romansivak@microsoft.com>
Co-authored-by: ssparach <128866445+ssparach@users.noreply.github.com>
Copilot-Session: 2b34993b-0dcf-4789-94c5-97fd92cce84d
Copilot-Session: 5474160f-e555-4254-899b-783ad9211b71
Copilot-Session: 484c9277-ea15-4f85-a4a0-0429347ade48
Copilot-Session: 16d7d2fc-3d7c-41e8-9999-0c2084ba9ea1
Copilot-Session: 38f0823a-2ee4-4c65-8f3f-7dde6a049509
Copilot-Session: 30bef3b6-3b91-4f20-96cd-7c242a8a370f
Copilot-Session: 6baeec26-f59b-466a-8eab-cd3b09b19380
Copilot-Session: e6b7e13d-59ce-4751-91f4-e8e589787837